Many complex, distributed systems use middle-ware such as the Common Object Request Broker Architecture (CORBA) as the mechanism to transfer data between hosts and sub-systems. Middle-ware is commonly used in systems to enable heterogeneous processors, Operating Systems (OSs), software languages, and architectures to inter-operate in a transparent fashion. Low-level details associated with network programming are abstracted from the software developer and interface software may be extended and re-used in an object-oriented manner. The physical peer host with which a host is communicating is also abstracted from the developer during development. This results in a challenging side-effect for end-users and integrators of systems that use this technology. At any given time, the host(s) that provide or receive specific data flows are not readily apparent, especially in cases where redundancy, fail-over, and significant quantities of data flows exist within the system architecture.
In systems, one can identify three primary tiers of hosts that participate in end-to-end data flow. At the front end are “Originators” that source the data, usually based on sensor or user input. Data from an Originator host may be provided to a second tier CORBA host (“Provider”) that is responsible for further distribution after appropriate processing. The third tier of the data flow is called a “Recipient”; it is the ultimate user of the data in the system. Therefore, a single data flow in the system can traverse multiple hosts along its end-to-end path. The transfer from one host to the next in the system can be quite complex. Further complicating the situation for the user or developer that seeks to understand the system's current interface status is the quantity of data flows in a complex system. Ultimately, when a complex system is running, it is difficult for a user or even a developer to know when a fault occurs and what the likely cause of the fault is. When a fault occurs, the process to determine which host is successfully providing the data flow or not providing the data flow, which host(s) should be receiving the data and actually are receiving the data flow, and where along that path, from the Originator to the Producer and to the Recipient things have gone wrong is extremely difficult.
Many middle-ware architectures exist to facilitate data transfer in a complex system. A subset of CORBA is briefly described herein as exemplary middle-ware architecture. CORBA is an object-oriented method for distributing data. As briefly described above, CORBA provides transparency to the application programmer, such that the application programmer does not need to know specifically which host is providing the data of interest. The application only needs to know the name of the required data object and the hostname of the CORBA Name Server (CNS).
To receive data in a typical Client/Server model, an application resolves the location of an object by obtaining an IIOP Object Reference (IOR) from the CNS for the object of interest. The IOR contains the information necessary for the Client to connect to the Server (e.g., Server IP address, etc). After obtaining the IOR for the object, the Client may perform method calls to the Server in accordance with the Interface Definition Language (IDL) defined for that object.
Another common model for transfer of data is the event channel of the Event Service, based on a data “push” paradigm. For an event channel, the Recipient subscribes to data of interest, the Provider makes its data available to the event channel as data updates occur (e.g. periodic sensor data), and the event channel “pushes” data to all Recipients that have subscribed to receive the data. The event channel is often co-located with the application that is generating data for the event channel. This is a one-to-many distribution model wherein the Provider is decoupled from direct interaction with the Recipient. For the event channel, as for the Client/Server, the CNS performs resolution of object names.
In systems of the prior art, there is no toolset to describe the complete data flow throughout a complex system that uses middle-ware such as CORBA such that a user can identify if any fault(s) exist, the cause of any fault(s), and the resultant system effects of interface fault(s). Some individual sub-systems have incorporated monitoring capability within their sub-system that contains checks to attempt to determine which interfaces are operational; however, this is done from the perspective of the single sub-system. In many target environments, there may be twenty or more sub-systems and numerous hosts, such that the status checks need to be performed from a total system perspective.
An example is now described for a system that includes distribution of Navigation data via a CORBA middle-ware event channel. Since Navigation data is usually a fundamental piece of data for successful operation of a platform, it is required by and distributed to multiple sub-systems in the system. In systems of the prior art, if a sub-system does not receive the depth object information, an operator within that sub-system cannot easily pinpoint the cause of the fault. Potential reasons are numerous and include events such as loss of a physical link (e.g., broken fiber), loss of the host operating as the Provider, loss of the host operating as the Originator, loss of the Recipient host, an incorrect IOR in the CNS subsequent to an event channel fail-over operation, etc. Regardless of the reason, the requested data was not received. In the systems of the prior art, an operator typically sees an error message to indicate that the Navigation data was not received. It is difficult for the operator to determine if the fault is isolated to that sub-system or if a more widespread problem exists in the system. The operator within the sub-system may contact other sub-system operators to attempt to ascertain the scope and cause of the fault.
One sub-system may show a warning at the bottom of the operator screen with status to identify that it is or is not receiving data, for instance, navigation depth data. Another sub-system may utilize a similar warning message. Thus, the two operators may communicate with each other to determine that navigation depth data is not being received, but they cannot immediately see why they are not receiving the data, or whether another sub-system is. There is no global view of the system's data distribution via middle-ware.